Can we turn this into a const enum such that it gets inlined? I believe we should be able to reference ScriptTarget from one. Or does that fail because of the type mismatch with ScriptTarget?

(Would like to limit our use of namespaces, honestly... plus potential perf hits here)

Or just a big const since we don't really need the reverse lookup (perf hit should be almost none)

It doesn't fail to match ScriptTarget, but it does produce its own type which doesn't illustrate the relationship when looking at the .d.ts file:

vs.

vs.

I actually still like namespace in moderation. This felt like an appropriate use for it, but I don't mind the as const. There's no perf difference between namespace and as const.

This is an internal declaration, so I don't personally feel like it's a big deal for the values to be opaque. It does make me wonder if we're missing something in declaration emit that would have reused those nodes, though.

Namespaces, as a concept, exist in both the standard library (Math, Atomics, Reflect) and the web platform (subtle, performance, etc.) so I don't agree that they should be wholly discouraged.

Sure, I'm just trying to avoid the runtime cost of them in the code we do control (e.g. const enums are inlined, modules are tree shaken).

If the perf results show a significant dip I can make it a const enum. It just feels less useful when hover information only shows the final value like 2 instead of something meaningful like ES2015.

I see what you mean; I do wish our hover and declaration emit did better here. But, we seem to just always compute in dts emit (not sure about hover).

I see what you mean; I do wish our hover and declaration emit did better here. But, we seem to just always compute in dts emit (not sure about hover).

It's arguable as to whether someone who writes const enum E2 { A = E1.B } would expect hover/d.ts to print the value or qualified name. With const variables or fields it's far clearer as to what to show. I could see maybe supporting const enum E2 { A = E1.B as E1.B } or something similar to explicitly opt-in to showing the qualified name, but that seems like a very niche use case.

I would much rather see (enum member) TypeFlags.Unit = Enum | Literal | UniqueESSymbol | Nullable than (enum member) TypeFlags.Unit = 109472. The actual computed values seem like the least important part of an enum.